是，但也不是。

薛丁格的貓也跑來寫程式了嗎？

下載完IDE就開始寫程式？這未免太快。

但容我借用一下別人的資料。

感謝同樣都是以Flutter為主題的鐵人參賽者「MarkFly～」，我這樣做完全沒有徵詢過他的同意與意見。

很遺憾，必須要說在安裝教學指引上，他寫得比我好。

但，動筆寫這系列的文目的在於「避免發生會殺死傻瓜」的問題，所以先別去太糾結這點。(臉皮厚。)

上面這張圖是最一開始啟動Android Studio後會看到的介面。介面分成左邊與右邊，左邊是「目前可以繼續編輯的專案」，右邊是「要開啟哪種類型的新/要開啟哪個舊專案/從其他地方匯入一個專案/...」。

第一次開啟IDE、第一次要開始寫程式碼的人，可以注意看紅框標註起來的功能「開啟一個新專案 Start a new Flutter project」，點選後開始大冒險...

+Start a new Flutter project

但...什麼是專案？

相較於各種工程科技技術來說，程式設計其實很年輕，產生的成品樣貌變化也非常快速。

過去程式大多是用終端機模式接受使用者操作跟輸出結果給使用者看，而今天有各種風格的視窗型UI在各種平台上運行，甚至還有根本沒有介面的背景程式、或程式內的插件Plugin這樣的東西。

最初，程式的功能都很單純，就好像SDK內的編譯器，就好像「複製檔案」這支程式。

對！「複製檔案」在過去是被做成一支獨立的程式被當成「作業系統的指令」在使用著。到Windows內終端機模式底下，大家依舊可以使用「copy」這個指令去決定要複製那些檔案、新檔案要如何命名...

但今天一支程式裡頭，「複製檔案/另存新檔」只是個「功能」，但奇妙的是：它的核心程式碼概念可能完全沒有不同。說白了，Word或各種Windows下的程式如果有複製檔案/另存新檔的功能，都只是在「呼叫copy這個指令」而已，大家都做法可能都一模一樣。

所以如果翻開Word的程式碼，很有可能就可以看到有一塊程式碼設計了一個「呼叫copy這個指令」的功能，──就是在不用開啟終端機的情況下讓使用者不知不覺就呼叫了這個指令，──或是極端一點，Word的程式碼裡面直接就內建/複製了完整的copy程式碼。

不管怎麼做，都會碰到一個問題：這功能都是別的程式已經做過的，需要自己重寫一次嗎？如果不想重寫，怎麼做會比較快？

當然不會有人覺得應該重寫一次，這是陷阱問題。

所以怎麼做呢？

把程式碼複製貼上

再次感謝有點氾濫又功能不良的資訊科普知識，這個答案雖然不能說錯，但完全不能用來表達為何會有「專案」這種東西的理由。

雖然專案的意義很多，但其中一樣就是要避免讓工程師依賴使用複製貼上。

所謂的專案可以理解成「它是眾多功能與介面的集合和引用」，例如剛剛提到Word內有複製檔案功能，如果複製檔案的功能叫「copy」，就會在Word的專案內看到一個名為「copy」的子專案，(命名方式並不是這麼死，如果高興也可以稱它為file_double，因為專案名稱不重要，內容才重要。)

或是我們可以反過來這樣描述：有個用來複製檔案的程式它的專案名稱為「copy」，而它被Word的專案給引用為子專案。

不只是「copy」這種功能，舉個抽象的例子：按鈕上的圖片會在滑鼠游標移過去時有動畫效果，如果動畫效果是種功能，是否要在每個按鈕內寫自己的動畫效果功能？

當然不用。把動畫效果獨立成一個子專案，讓每個需要動畫效果的按鈕呼叫它即可。

使用「專案」這樣的概念讓工程師們可以方便的管理和擴充自己的程式碼，只要引用其他程式的專案，就可以擁有該程式的功能。不只如此──其他程式如果修正了自己的Bug，也可以即刻獲得修正，這是複製貼上做不到的。

複製貼上的程式碼如果有Bug，修正時會讓工程師忍不住想要捏心肝自殺。

工程師忍不住想要捏心肝自殺：<翻譯>程式碼無法維護擴充升級，導致必須要廢棄掉將整個程式重作。

但，怎麼引用其他專案？

糟糕！這個議題是個大到不知道怎麼塡的坑，真去填的價值也不大。

因為重點在於知道這個議題的存在，知道後要能「從寫程式的第一天開始，就要有將自己的程式規劃成各種功能、並用子專案管理它們的習慣。」(看過很多工程師雖然使用著有專案功能的程式語言與IDE在寫程式，卻從不對自己的程式碼做真正有效有意義的專案管理，只是形式上列幾個專案、知道從網路上引用別人的專案好方便，但程式碼大多數都是在複製貼上。)

以上是種「何謂專案」的抽象概念。

實際上，專案就是種檔案資料結構。可以在下面這張圖的左半邊看到一個類似檔案管理的介面，那就是「專案」。

所以專案其實也可以用一般的檔案管理員來看。（下一篇會講到：建立專案的時候為指定一個「檔案位置」。可以用檔案管理員找到這個路徑。）

為什麼要知道這個？

首先，開啟IDE很耗資源。如果今天要做的事情並不包含編譯，頂多是查閱程式碼，那與其IDE開啟專案，不如用檔案管理員開啟後搭配普通的文書編輯軟體開啟程式碼檔案就好。(因為是「傻瓜也要能看懂」，所以我覺得有必要說明這點。)

其次，這會反映出IDE的運作原理，程式碼專案內的各個文件、各篇程式碼、各種圖檔或影音資源檔案...這些並不是專案的全貌，IDE會在專案內設置很多檔案來讓自己進行專案管理。──這件事情聽起來很饒舌，但這個觀念卻也是很多功能的基礎，就是讓程式去閱讀(分析)某些檔案內容來決定自己接下來要做什麼事情。

比如編譯這件事。IDE如果要編譯一個專案，它如何知道專案範圍呢？難道要整個硬碟都掃描一次、檢視每個檔案是否都可以編譯嗎？方法一，在專案的根目錄內留下一個獨特的檔案，如果發現這個檔案存在於這層資料中，IDE就會知道沒有必要再往上分析和搜尋可否有可編譯的檔案。方法二，在IDE內自己建立一個資料檔案，裡面有各個專案的紀錄。

哪個方法其實不重要，因為它們的原理是類似的，只是使用這個原理的策略不一樣，而且除了在IDE內管理專案的經驗差不多以外，使用檔案管理員時的體驗會差很多。

像：方法一在使用檔案管理員移動專案時，可以保證專案可以再次被IDE開啟，但方法二就不行。(因為專案軟體不會知道你操作了檔案管理員，它內建的檔案內容不會更新，導致它要依照檔案內容去開啟專案時，會找不到專案...或類似的錯誤。)

很奇妙的一點：以上知識的原理就算一個都不曉得，只知道按照指示去安裝、啟動、建立專案，大家依舊可以開開心心的開始寫程式。

......我好像聽到有人讀到這段話後理智差點斷線的味道。